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PREFACE 


This  report  describes  the  work  performed  under  the  Assured  Service  Concepts  and  Models  (ASCM) 
contract.  The  work  was  supported  by  Rome  Laboratory  under  the  ASCM  contract  (contract 
no:  F30602-90-C-0025).  The  prime  contractor  is  the  Secure  Computing  Technology  Corporation 
(SCTC)  and  the  sub-contractor  is  the  Georgia  Tech  Research  Corporation  (GTRC).  This  report 
overviews  all  of  the  work  performed  on  the  contract. 

The  ASCM  project  began  in  April  1990;  the  technical  work  was  completed  in  May  1991. 

The  SCTC  team  members  were  Mike  Endrizzi,  Todd  Fine,  Tom  Ilaigh,  Richard  O’Brien,  and  Bill 
Wood.  The  GTRC  team  member  was  Sudhakar  Yalamanchili. 
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SECTION  1 


INTRODUCTION 


This  document  summarizes  the  work  performed  on  the  ASCM  project.  Details  are  provided  in  the 
attached  volumes. 

l.l  OBJECTIVE 

The  objective  of  the  ASCM  project  was  to  develop  approaches  for  analyzing  secure,  distributed  C2 
systems.  The  objective  was  met  by  completing  the  following  tasks: 

a.  Perform  a  study  to  determine  the  secrecy  and  availability  needs  for  distributed  C2  systems 
and  the  relationship  between  secrecy  and  availability  in  distributed  C2  systems. 

1).  Perform  a  study  to  determine  the  appropriate  modeling  formalism  to  use  for  the  analysis  of 
distributed  C2  systems  with  respect  to  secrecy  and  availability. 

c.  Develop  adaptive  secrecy  policies  that  are  appropriate  for  analyzing  distributed  C2  systems. 

d.  Develop  availability  models  that  are  appropriate  for  analyzing  distributed  C2  systems. 

e.  Examine  approaches  for  identifying  trade-offs  that  must  be  made  between  secrecy  and  avail¬ 
ability  in  distributed  C2  systems. 


1.2  ACCOMPLISHMENTS 

The  ASCM  project  has  achieved  a  number  of  significant  accomplishments.  They  include: 

a.  Identifying  the  ways  that  various  availability  mechanisms  both  complement  and  conflict  with 
secrecy  policies. 

b.  Identifying  the  advantages  and  disadvantages  of  using  various  modeling  formalisms. 

c.  Clarifying  the  relationships  among  various  security  policies. 

d.  Identifying  deficiencies  in  previously  developed  information  flow  policies  for  nondeterministic 
systems. 

e.  Developing  adaptive  security  policies. 

f.  Demonstrating  that  composability  is  a  requirement  for  security  policies  rather  than  only  a 
desirable  property. 

g.  Identifying  deficiencies  in  proposed  approaches  for  using  composability  to  significantly  simplify 
a  security  analysis. 

h.  Developing  an  approach  for  formally  analyzing  fault  tolerance  mechanisms. 


i.  Developing  liveness  policies  that  prohibit  deadlock,  starvation,  and  mutual  starvation. 

j.  Developing  a  worked  example  of  the  analysis  of  a  real-time  system. 

k.  Developing  approaches  for  identifying  trade-offs  between  secrecy  and  availability  in  distributed 
C2  systems. 

Wo  discuss  each  of  these  results  in  more  detail  in  the  following  sections. 

1.3  DOCUMENTS 

The  ASCM  final  report  is  organized  as  follows.  Volume  1  (this  document)  is  a  summary  of  the 
report.  It  summarizes  all  of  the  work  done  on  the  ASCM  project.  Volume  2  (CDRL  A005)  describes 
the  various  security  policies  that  were  developed  on  the  contract.  Volume  3  (CDRL  A 004)  describes 
the  availability  policies  that  were  developed  on  the  contract  and  the  approaches  that  were  developed 
for  identifying  trade-offs  between  secrecy  and  availability.  Volume  3  also  contains  the  findings  of 
the  formalism  study. 
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SECTION  2 


FORMALISMS  STUDY 


Volumes  2  and  3  contain  the  results  of  the  formalisms  study  task. 

Volume  2  describes  how  a  deficiency  in  modeling  formalisms  has  greatly  complicated  the  formaliza¬ 
tion  of  secrecy  in  an  information  flow  policy.  The  deficiency  is  that  modeling  formalisms  typically 
ignore  causality.  For  example,  while  it  is  easy  to  specify  that  a  particular  output  can  never  come 
before  a  particular  input,  it  is  difficult  to  specify  that  the  input  causes  the  output.  The  relevance  to 
information  flow  policies  is  that  this  deficiency  makes  it  very  difficult  to  distinguish  high-level  events 
that  are  caused  by  low-level  processes  from  other  high-level  events.  Informally,  an  information  flow 
policy  requires  that: 

Actions  taken  by  high-level  processes  are  not  visible  to  low-level  processes. 

This  policy  is  formalized  by  requiring  that  the  results  visible  at  the  low-level  are  the  same  regardless 
of  whether  the  high-level  actions  occur.  The  process  of  removing  the  parts  of  the  execution  history 
caused  by  high-level  actions  is  referred  to  as  purging  the  high-level  actions.  A  high-level  action 
consists  of  the  set  of  events  that  it  causes.  Thus,  we  must  determine  which  events  are  caused  by 
a  high-level  action  before  we  can  purge  the  action.  Because  it  is  difficult  to  tell  which  events  are 
caused  bv  a  high-level  action,  it  is  difficult  to  correctly  purge  high-level  actions.  Volume  2  argues 
that  the  many  failures  in  developing  an  information  flow  policy  for  nondeterministic  systems  are 
a  result  of  the  lack  of  a  notion  of  causality.  Further  research  into  this  area  would  greatly  benefit 
the  theory  of  information  flow  policies  for  nondeterministic  systems.  This  issue  is  related  to  the 
discussion  of  composability  in  the  next  section. 

Volume  3  considers  the  following  formalisms  in  more  detail:  state  machines,  traces  (and  more 
generally,  CSP),  Petri  nets,  temporal  logic,  interval  temporal  logic  (ITL),  and  real  time  logic 
(RTL).  The  advantages  and  disadvantages  of  each  formalism  are  discussed  and  a  list  is  provided  of 
the  problem  domains  to  which  each  is  applicable.  CSP  was  found  to  be  the  most  useful  formalism 
for  distributed  C2  systems  except  for  the  case  ir  which  the  system  must  be  analyzed  with  respect 
to  a  real-time  policy.  Since  there  does  not  appear  to  be  any  way  to  “correctly”  incorporate  real- 
time  into  CSP,  some  other  formalism  must  be  used  for  real-time  policies.  Some  peculiarities  in  the 
semantics  of  RTL  make  it  difficult  to  use,  and  non-trivial  ITL  specifications  are  very  difficult  to 
understand.  Thus,  neither  ITL  nor  RTL  appear  useful  for  addressing  real-time  policies.  Instead, 
we  found  timed  state  predicates,  a  variant  of  RTL,  to  be  the  most  useful. 


5 


SECTION  3 


SECRECY  POLICY  DEVELOPMENT 


Volume  2  contains  an  informal  description  of  a  simple  C2  system.  This  system  is  used  to  motivate 
the  discussion  of  security  policies.  Volume  2  also  discusses  the  various  security  policies  that  are 
currently  in  use.  Where  possible,  relationships  between  policies  are  described.  In  particular,  a 
description  is  given  of  how  newer  policies  address  the  deficiencies  in  previous  policies. 

Since  distributed  C2  systems  are  nondeterministic  to  a  certain  degree,  secrecy  policies  for  nonde¬ 
terministic  systems  must  be  developed  before  secrecy  policies  can  be  developed  for  distributed  C2 
systems.  Volume  2  describes  deficiencies  in  current  formalizations  of  information  flow  policies  for 
nondeterministic  systems  and  proposes  a  series  of  new  definitions  that  address  these  deficiencies. 
Two  areas  that  must  be  researched  further  are: 

a.  The  use  of  stochastic  information  flow  policies  to  address  noisy  covert  channels. 

Although  we  propose  a  stochastic  information  flow  policy,  further  research  is  required  to 
determine  the  feasibility  of  using  it  to  analyze  a  real  system. 

b.  Viewing  computer  systems  as  self-evolving  systems  rather  than  assuming  that  requests  are 
generated  external  to  the  system. 

The  behavior  of  a  subject  in  a  computer  system  is  defined  by  the  subject’s  code  object  and  the 
system’s  scheduling  policy  rather  than  by  actions  external  to  the  system.  Since  information 
flow  policies  usually  ignore  the  connection  between  a  subject’s  code  object  and  the  system’s 
scheduling  policy  and  the  instructions  the  subject  executes,  it  is  possible  that  a  system  might 
satisfy  an  information  flow  policy  while  still  allowing  a  covert  channel  through  executable 
objects  or  the  scheduling  policy.  Further  research  is  required  to  develop  a  formal  security 
policy  that  addresses  this  deficiency. 

After  developing  a  firm  foundation  for  secrecy  policies,  Volume  2  discusses  adaptive  security  policies. 
An  adaptive  secrecy  policy  is  one  that  addresses  special  operations  that  violate  the  letter  of  an  MLS 
policy.  Examples  include: 

a.  The  reclas  'fication  of  processes  and  data. 

I).  Reconfiguration  of  a  system. 

c.  Broadcast  messages  across  levels. 

d.  Change  of  operational  mode. 

The  violations  can  be  separated  into  two  classes,  those  that  can  actually  compromise  the  sensitive 
information  and  those  that  cannot.  The  second  class  consists  of  trusted  subjects  whose  design 
prevents  them  from  disclosing  information  at  an  inappropriate  level  even  though  they  have  privilege 
to  downgrade  information.  The  former  class  contains  the  rest  of  the  trusted  subjects. 
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Volume  2  describes  a  policy  that  can  be  used  to  incorporate  the  analysis  of  the  second  class 
of  trusted  subjects  with  the  analysis  of  the  untrusted  subjects  and  to  clearly  identify  that  the 
remaining  trusted  subjects  are  exceptions  that  must  be  analyzed  using  some  other  means.  Since 
this  approach  is  much  more  unified  than  the  traditional  approach,  it  provides  a  more  complete 
and  believable  analysis.  Volume  2  also  discusses  how  this  approach  can  be  simplified  if  the  system 
being  analyzed  enforces  a  role  enforcement  policy  such  as  Type  Enforcement  or  Clark-Wilson  policy. 
Role  enforcement  policies  provide  the  capability  of  constraining  trusted  subjects  based  on  their  role 
in  the  system.  For  example,  suppose  a  system  contains  a  subject  D  that  is  trusted  to  downgrade 
information  after  it  has  sanitized  it.  Since  D  is  trusted  to  violate  the  system’s  MLS  policy,  the  MLS 
policy  places  no  constraints  on  D.  Thus,  if  the  system  only  enforces  an  MLS  policy,  the  system  has 
no  control  over  D's  actions.  On  the  other  hand,  if  the  system  enforces  a  role  enforcement  policy, 
then  the  system  can  enforce  the  policy  that  D  must  sanitize  information  before  downgrading  it. 

Volume  2  also  considers  the  relevance  of  composability  to  secrecy  policies.  Previous  work  has 
suggested  that  while  composability  is  des'rable  it  is  only  necessary  when  a  system  is  constructed  by 
combining  components  that  are  individually  shown  to  be  secure.  Our  findings  were  that  any  policy 
that  is  not  composable  is  seriously  Hawed.  The  notion  of  composability  was  developed  to  address 
flaws  that  were  observed  in  existing  information  flow  policies.  Volume  2  shows  that  these  flaws  were 
the  result  of  the  underlying  formalisms  not  providing  a  notion  of  causality.  The  noncomposability 
of  the  policies  is  a  consequence  of  ignoring  causality.  The  importance  of  these  findings  is  that  they 
suggest  that  future  research  should  be  directed  at  addressing  causality  rather  than  at  developing 
composable  policies. 

In  addition  to  raising  doubt  as  to  the  theoretical  importance  of  composability,  Volume  2  also  ques¬ 
tions  its  practical  importance.  Earlier  work  has  suggested  that  a  complex  system  can  be  demon¬ 
strated  to  be  secure  by  demonstrating  that  it  is  a  composite  of  pieces  that  satisfy  a  composable 
security  policy.  There  are  two  problems  with  using  this  approach. 

a.  Policies  arc  composable  with  respect  to  a  specific  method  for  composing  systems.  If  the  imple¬ 
mentation  of  a  system  uses  a  different  method  for  composing  systems,  then  the  composability 
argument  is  no  longer  valid. 

b.  In  the  process  of  decomposing  the  system,  a  level  is  reached  at  which  the  components  are  no 
longer  secure  in  isolation;  instead,  the  components  constrain  each  other  so  that  the  overall 
system  is  secure. 
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SECTION  4 


AVAILABILITY  MODEL  DEVELOPMENT 


Volume  3  describes  our  approach  to  analyzing  a  distributed  C2  system  with  respect  to  availability. 
The  approach  is  to: 

a.  Develop  a  specification  of  the  system  ignoring  the  possibility  of  faults. 

b.  Determine  the  set  of  faults  to  be  tolerated  and  the  effects  of  each  fault. 

c.  Extend  the  specification  of  the  system  to  address  the  possibility  of  faults. 

d.  Demonstrate  that  the  system  satisfies  our  fault  tolerance  policy. 

e.  Demonstrate  that  the  CSP  specification  that  ignores  the  possibility  of  faults  satisfies  any  of 
on i  availability  policies  that  are  desired. 

Our  fault  tolerance  policy  requires  that  the  input-output  behavior  of  a  service  be  unaltered  by  the 
occurrence  of  faults.  Thus,  we  can  reduce  the  analysis  of  the  system  to  simply  analyzing  the  non- 
faultv  behavior  of  the  system  by  showing  the  system  is  fault  tolerant.  Although  our  fault  tolerance 
is  similar  in  spirit  to  previously  proposed  fault  tolerance  policies,  it  addresses  deficiencies  present 
in  earlier  work. 

We  also  considered  two  ways  to  weaken  our  fault  tolerance  policy  to  obtain  a  graceful  degradation 
policy.  The  first  way  is  to  allow  the  set  of  faults  with  respect  to  which  the  system  is  fault  tolerant 
to  decrease  with  time.  The  correspondence  between  this  situation  and  graceful  degradation  of 
service  is  that,  the  system’s  ability  to  tolerate  faults  degrades  with  time.  The  second  way  to  weaken 
our  policy  is  to  allow  faults  to  alter  the  input-output  behavior,  but  to  require  that  the  faulty 
behavior  be  “similar”  to  the  non  faulty  behavior.  Since  the  system  behavior  is  altered  by  faults,  it 
is  degraded.  The  degradation  is  graceful  in  the  sense  that  the  faulty  behavior  must  be  “similar”  to 
the  nonfaultv  behavior.  Further  research  is  needed  to  complete  the  formalization  of  these  forms  of 
graceful  degradation  and  determine  their  applicability  to  realistic  systems. 

Volume  3  discusses  CSP  formalizations  of  policies  prohibiting  deadlock,  starvation,  and  mutual 
starvation.  In  addition,  Volume  3  describes  how  concepts  such  as  temporal  dependence,  eventuality, 
livelock,  and  fairness  can  be  formalized  in  CSP.  Although  the  policies  were  developed  in  the  context 
oT  deterministic  systems,  we  propose  generalizations  to  nondeterministic  systems.  Informally,  the 
policies  are: 

•  Deadlock  Policy 

Given  any  set  of  processes  that  are  not.  permitted  to  deadlock,  whenever  there  are  events  e  and 
f  such  that  one  of  the  processes  can  participate  in  e  Itefore  f,  all  of  the  processes  in  the  set 
must  participate  in  e  before  f. 

Otherwise,  deadlock  would  occur  since  one  process  would  attempt  to  perform  e  before  /  while 
another  process  would  attempt  to  perform  /  before  e. 
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•  Starvation  Policy 

Given  any  two  processes  P  and  Q  such  that  P  is  not  permitted  to  starve  Q,  P  must  interact 
with  Q  whenever  Q  requests  interaction. 

Otherwise,  Q  would  be  indefinitely  blocked  waiting  for  service  from  P. 

•  Mutual  Starvation  Policy 

Given  any  two  processes  P  and  Q  that  are  not  permitted  to  starve  each  other,  whenever  P  and 
Q  interact,  they  do  so  in  a  consistent  manner. 

Otherwise,  P  and  Q  would  each  be  indefinitely  blocked  waiting  for  the  other  to  use  the  proper 
protocol  for  the  interaction. 

If  absolute  availability  is  required,  then  the  sets  of  processes  permitted  to  deny  service  are  defined 
to  be  empty.  For  example,  by  specifying  that  no  sets  of  processes  are  permitted  to  be  deadlocked, 
the  deadlock  policy  prohibits  any  deadlock  from  occurring  in  the  system.  On  the  other  hand,  a 
policy  that  only  prohibits  system  services  from  becoming  deadlocked,  while  allowing  user  processes 
to  become  deadlocked,  would  be  obtained  by  defining  the  sets  of  processes  that  are  permitted  to 
be  deadlocked  so  that  none  of  them  include  any  system  services. 

Further  work  is  necessary  to  demonstrate  the  validity  of  these  policies  and  to  develop  policies  for 
other  classes  of  availability  concerns. 

Since  real-time  policies  are  more  application  depend*  t  than  liveness  policies,  Volume  3  provides 
a  worked  example  of  the  analysis  of  a  simple  real-time  system  rather  than  a  general  discussion  of 
real-time  policies.  The  system  is  an  elevator  control  system  that  was  developed  by  SRI  using  the 
ITL  specification  language.  We  found  timed  state  predicates  to  be  a  much  more  useful  specification 
for  the  elevator  example.  In  addition  to  discovering  some  significant  errors  in  the  ITL  specification, 
we  were  also  able  to  provide  an  argument  that  the  elevator  satisfied  its  service  policy.  In  contrast, 
the  SRI  work  only  included  a  specification  of  the  elevator  and  performed  no  analysis  of  the  model. 
Although  our  work  with  real-time  policies  was  specific  to  the  elevator  example,  it  appears  reasonable 
to  adapt  the  approach  to  address  real-time  policies  for  other  systems.  Further  research  is  needed 
to  determine  whether  this  actually  is  feasible. 
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SECTION  5 


TRADE-OFF  STUDY 


Volume  3  also  discusses  approaches  that  can  be  used  to  identify  trade-offs  between  secrecy  and 
availability. 

We  found  that  the  most  reasonable  way  to  address  trade-offs  between  secrecy  and  availability  is  to 
weaken  the  respective  policies  to  obtain  a  policy  that  clearly: 

a.  Identifies  the  conflicts  between  secrecy  and  integrity, 

I).  Identifies  the  degree  of  secrecy  and  integrity  that  holds  in  each  case  of  conflict, 
c.  Identifies  the  absolute  policies  that  hold  when  there  are  no  conflicts. 

l  or  example,  the  policies  developed  in  Volume  2  can  be  used  to  define  exactly  which  system 
operations  violate  the  secrecy  policy.  A  complete  policy  can  be  obtained  by  extending  the  policy 
to  define  the  permissible  actions  the  system  can  take  for  each  of  the  exceptions.  Other  ways  of 
weakening  policies  to  remove  conflicts  include  stochastic  policies  and  the  concept  of  effectively 
ignoring.  For  example: 

•  By  using  a  stochastic  policy,  it  is  possible  to  have  the  secrecy  policy  allow  noisy  covert  chan¬ 
nels  while  prohibiting  noiseless  covert  channels.  A  common  approach  to  addressing  conflicts 
between  secrecy  and  availability  is  to  introduce  an  availability  mechanism  at  the  expense  of 
a  noisy  covert  channel.  By  using  a  stochastic  policy  it  is  possible  to  demonstrate  that  the 
channel  is  noisy  and  to  determine  the  amount  of  noise  present. 

•  If  the  purging  of  high-level  actions  is  defined  to  only  ignore  certain  parts  of  high-level  actions 
rather  than  all  high-level  actions,  then  we  say  that  the  high-level  actions  are  effectively  ignored 
rather  than  completely  ignored.  If  a  system  can  be  shown  to  satisfy  an  information  flow  policy 
with  this  weaker  notion  of  purging,  then  the  system  is  demonstrated  to  only  have  information 
flow  through  the  parts  of  the  high-level  actions  that  were  not  purged.  By  more  accurately 
identifying  the  source  of  the  illicit  information  flow,  further  analysis  of  the  system  is  simplified. 
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SECTION  6 


RESEARCH  TOPICS 


In  this  section  we  list  issues  that  the  project  did  not  completely  address: 

a.  Although  we  identified  the  lack  of  any  notion  of  causality  as  a  deficiency  in  many  modeling 
formalisms,  we  failed  to  identify  a  formalism  that  addressed  the  deficiency.  After  finding  such 
a  formalism,  it  would  be  interesting  to  use  it  to  state  an  information  flow  policy  and  see 
whether  all  of  the  problems  present  in  current  information  flow  policies  are  addressed. 

b.  Our  policy  that  views  a  system  as  self-evolving  rather  than  responding  to  external  requests 
must  be  formalized. 

c.  Our  policies  for  graceful  degradation  of  service  must  be  formalized. 

d.  The  original  plan  for  the  ASCM  project  called  for  research  into  the  composition  of  heteroge¬ 
neous  security  policies.  We  intended  to  address  this  by  working  examples  of  general  instances 
of  the  composition  of  heterogeneous  systems.  This  would  have  resulted  in  a  library  of  generic 
examples  that  could  be  used  when  analyzing  a  specific  system.  We  did  not  have  time  to 
perform  this  work  on  the  contract. 

e.  We  developed  as  many  service  policies  as  time  permitted,  but  there  are  still  classes  of  avail¬ 
ability  policies  that  are  not  addressed. 

f.  The  original  plan  for  the  ASCM  project  called  for  the  policies  and  models  developed  on  the 
project  to  be  applied  to  the  THETA-DOS  operating  system.  This  would  provide  validation  of 
the  approach  and  serve  as  a  guide  for  future  efforts  to  develop  and  analyze  secure,  distributed 
C2  systems.  Unfortunately,  there  was  not  enough  time  on  the  contract  to  perform  this 
analysis.  It  is  important  that  the  policies  and  models  be  validated  by  using  them  to  analyze 
a  moderately  complex  system.  In  particular,  the  following  policies  and  models  should  be 
applied  to  such  a  system: 

(1)  Our  adaptive  information  flow  policy, 

(2)  Our  stochastic  information  flow  policy, 

(3)  Our  policy  viewing  a  system  as  self-evolving  rather  than  responding  to  external  requests, 

(4)  Our  fault  tolerance  and  graceful  degradation  policies, 

(5)  Our  deadlock,  starvation,  and  mutual  starvation  policies, 

(6)  Our  approach  for  analyzing  systems  with  respect  to  real-time  policies. 

The  approaches  we  have  identified  for  performing  trade-offs  between  secrecy  and  availability 
should  be  used  to  address  any  conflicts  that  arise  during  the  analysis. 
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SECTION  7 


CONCLUSION 


The  ASCM  project  has  met  its  goal  of  developing  an  approach  for  analyzing  distributed  C2  systems 
with  respect  to  both  secrecy  and  availability.  In  addition  to  pulling  earlier  work  together  into  a 
unified  approach,  the  project  addressed  deficiencies  that  were  present  in  the  earlier  work  by  defining 
new  policies  and  models.  The  most  serious  deficiencies  in  the  work  performed  on  the  contract  are: 

•  More  realistic  examples  are  needed  to  validate  the  approach  developed. 

•  More  classes  of  policies  and  models  need  to  be  defined. 
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